Although the Internet has had great successes in facilitating communications between computer systems and enabling electronic commerce, the computer systems connected to the Internet have been under almost constant attack by hackers seeking to disrupt their operation. Many of the attacks seek to exploit vulnerabilities of the application programs or other computer programs executing on those computer systems. One of the most destructive methods of attacking a computer system has been to send a “worm” to a computer program. A worm is a self-propagating attack that exploits a vulnerability by taking control of the computer system and using that computer system to launch attacks (i.e., send the same worm) against other computer systems with the same vulnerability. A worm is a message or sequence of messages designed to exploit a vulnerability of the receiving computer program. Upon receiving the message or messages, the computer program performs some action that allows the worm to take control of the computer system.
Developers of applications and administrators of computer systems go to great effort and expense to identify and remove vulnerabilities. Because of the complexity of applications, however, it is virtually impossible to identify and remove all vulnerabilities before applications are released. After an application is released, developers can become aware of vulnerabilities in various ways. A party with no malicious intent may identify a vulnerability in an application and may secretly notify the developer so the vulnerability can be removed before a hacker identifies and exploits it. If a hacker identifies a vulnerability first, the developer may not learn of the vulnerability until it is exploited—sometimes with disastrous consequences.
Regardless of how a developer finds out about a vulnerability, the developer typically develops and distributes to system administrators “patches” that remove the vulnerability. If the vulnerability has not yet been exploited (e.g., might not be known to hackers), then a developer can design, implement, test, and distribute a patch in a disciplined way. If the vulnerability has already been widely exposed, then the developer may rush to distribute a patch without the same care that is used under normal circumstances. When patches are distributed to the administrators of the computer systems, they are responsible for scheduling and installing the patches to remove the vulnerabilities.
Unfortunately, administrators often delay the installation of patches to remove vulnerabilities for various reasons. When a patch is installed, the application and possibly the computer system on which it is executing may need to be shut down and restarted. If the vulnerability is in an application that is crucial to the success of an organization, then the administrator needs to analyze the tradeoffs of keeping the application up and running with its associated risk of being attacked and of shutting down a crucial resource to install the patch. Some administrators may delay the installation of the patch because they fear that, because of a hasty distribution, it might not be properly tested and have unintended side effects. If the patch has an unintended side effect, then the application (or the computer system) may be shut down by the patch itself. Administrators need to factor in the possibility of an unintended side effect when deciding whether to install a patch. These administrators may delay installing a patch until experience by others indicates that there are no serious unintended side effects.
Other methods are available for preventing the exploitation of vulnerabilities in applications. For example, if the source of an exploitation is known, then all messages from that source can be intercepted and discarded before they reach the application. The source of the attack, however, may not be precisely identifiable, resulting in messages from many benign sources also being discarded. As another example, a message that is attempting to exploit a vulnerability may have a characteristic (e.g., a file name that is too long) that can be detected and discarded before it is sent to the application.
Current methods for preventing exploitation of vulnerabilities are not completely satisfactory for various reasons. The installation of patches is not completely satisfactory because some administrators simply may not install patches fast enough to prevent exploitation of the vulnerabilities. Moreover, a patch could itself have side effects that are more disastrous than the exploitation of the vulnerability. The intercepting of messages to identify an attempted exploitation is also not completely satisfactory because the identifications are based on known exploitations and may not prevent unknown exploitations of the same vulnerability. It would be desirable to prevent the exploitation of vulnerabilities in a way that does not require patches and that is independent of any particular exploitation of the vulnerability.